Many modern applications work on an n-tier architecture in which a web-based user interface (UI) makes a call to a webservice which in turn retrieves data from a data storage system. In the last few years, the service layer has been standardized across the industry to use RESTful webservices that work based on a JSON input and output structure. Most new service layer implementations currently use this standard.
In software engineering, unit testing is a process by which individual units of source code are tested to determine if they are acceptable for use. A unit refers to the smallest testable part of a software application. In addition to unit testing, it is desirable to conduct service layer testing, since service layer testing reveals whether independently working unit tests give the expected result when combined together. Regression testing is also beneficial. Regression testing refers to the testing of software that has been previously tested to determine whether it still performs correctly after being modified or interfaced with other code. During regression testing, new bugs or regressions may be discovered.
Though service layer testing and regression are very desirable, there is no easy way to conduct them, since each service takes in a unique input JSON file and responds with a JSON output file that is unique to the particular service request. As such, to achieve 100% service layer testing, developers need to spend a significant amount of time forming input service requests manually and then need to manage these requests over the active lifecycle of the application. This approach is cumbersome and leads to service test cases going stale relatively frequently for the following reasons. First, developers need to manually code the service requests. The manual coding process introduces a significant risk of human error and takes significant time. As a workaround, development teams often decide to conduct service layer testing of only a subset of all services, thereby compromising the thoroughness of the testing. Second, if there are any changes to an existing service input structure due to a business requirement, then the developer must go back and update the input request that is already stored. Third, if the underlying data changes, then the same services that were responding well to the given input will no longer behave well. Thus, the developer must go back and update the data parameters of the service request. Finally, any additional service that is created or requested in the future will need to go through the foregoing steps 1, 2 and 3. Hence, known service layer testing processes require continual attention and maintenance. These and other drawbacks exist with known systems and processes.